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Programmkomponentensystems" 



am 20. Februar 1998 beim Deutschen Patent- und Markenamt eingereicht 
und erklart, dad sie dafur die Innere Prioritat der Anmeldung in der 
Bundesrepublik Deutschland vom 2. Januar 1998, Aktenzeichen 198 00 102.9, 
in Anspruch nimmt. 

Die angehefteten Stucke sind eine richtige und genaue Wiedergabe der ursprung- 
lichen Unterlagen dieser Patentanmeldung. 

Die Anmeldung hat im Deutschen Patent- und Markenamt vorlaufig das Symbol 
G 06 F 9/44 der International Patentklassifikation erhalten. 




Munchen, denJ.3_Januar 1999 
Deutsphes Patent- und Markenamt 
>ra6ident 



Aktenzeichen: 198 07 191.4 




Nietie& 



A9161 

6.90 

(EDV-L) 

01/98 



acOlde 
ACQS . . . 




1 



Programmablaufverf ahren und Verfahren zur Erweiterung eines 
Programmkomponentensys terns 

5 Die Erfindung betrifft den Programmablauf sowie die Erstel- 
lung eines Programmkomponentensys terns, das auch als "Compo- 
nentware" bezeichnet wird. Insbesondere betrifft die Erfin- 
dung ein Programmablaufverf ahren bei einem Programmkoxnpo- 
nentensystem sowie ein Verfahren zur Erweiterung eines sol- 
10 chen Systems. 



In dem Artikel "Componentenware - von der Komponente zur 
Applikation" von Michael Stal, erschienen in der Zeitschrift 
OBJEKTspektrum, Heft 3, 1997, Seiten 86 bis 89, sind Grund- 
15 lagen von Programmkomponentensystemen beschrieben. Die Ziel- 
setzung ist es, die bisher erf orderliche, sehr zeitauf wendi- 
ge Sof twareerstellung durch ein blofces "Verdrahten" vorgege- 
bener Komponenten zu ersetzen. Diese Komponenten sollen in 
unterschiedlichen Kontexten eingesetzt werden konnen, ohne 
20 daJi der Komponentenproduzent Details des einer Komponente 
zugrundeliegenden Source-Codes bekanntgeben muilte. 

Zur Produktion von Componentware sind mehrere sich erganzen- 
de Technologien bekannt, darunter Verteilungsplattf ormen, 
Containerplattf ormen und die Verbunddokumenten-Technologie . 

Bei Verteilungsplattf ormen werden Konventionen und Werkzeuge 
fur die Verteilung von Komponenten uber Rechnergrenzen hin- 
weg sowie zur Kommunikation zwischen den Komponenten bereit- 
30 gestellt. Als Quasi-Industriestandards haben sich folgende 
Verteilungsplattf ormen durchgeset zt : DCOM (Distributed Com- 
ponent Object Model) von Microsoft, CORBA (Common Object 
Request Broker Architecture) von der OMG (Object Management 
Group), JAVA-RMI (Remote Method Invocation) von JavaSoft. 

35 



Containerplattf ormen beinhalten eine losungsorientierte 
Menge von Sof twarekomponenten zur zumindest teilweisen 
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Abdeckung eines bestimmten Auf gabenbereichs (zum Beispiel 
Lagerwesen, Finanzbuchhaltung, . . . ) und eine losungsneutrale 
Middleware (wie zum Beispiel eine graphische Benutzer- 
schnittstelle) , um eine Interaktion zwischen den Komponenten 
5 und dem Benutzer zu ermoglichen. 

Die Verbunddokumenten-Technologie ermoglicht eine Integra- 
tion unterschiedlicher Applikationen . Ein Verbunddokument 
umfafit mehrere Bestandteile (zum Beispiel Tabellen f Grafi- 
10 ken, Texte, . ..), fur die je eine Applikation verantwortlich 
ist. Bekannte Architekturen fur Verbunddokumente sind bei- 
spielsweise ActiveX von Microsoft, OpenDoc von CILab und 
Java Beans von JavaSoft. 

15 Bei den verfugbaren Verfahren besteht jedoch das Problem, 

daJi die Funktionalitat einer Komponente ausschliefilich iiber 
Schnittstellen genutzt werden kann, die von dem Komponenten- 
produzenten vordefiniert worden sind. Diese Schnittstellen 
sind insbesondere die vom Komponentenproduzenten vordefi- 
20 nierten Methoden oder Parameter. Es besteht keine Moglich- 
keit, die Funktionalitat einer Komponente unabhangig vom 
Komponentenproduzenten zu erweitern, da der Source-Code der 
Komponente im allgemeinen nicht verfiigbar ist. Eine blolie 
Parametrisierungsmoglichkeit , wie sie gegebenenf alls vorge- 
sehen sein kann, stellt keine Erweiterung der Funktionalitat 
einer Komponente dar, da alle moglichen Funktionen bereits 
urspriinglich vom Komponentenproduzenten vorgesehen sein miis- 
sen . 



30 Die Erfindung hat demgemafi die Aufgabe, bei einem Programm- 
komponentensystem eine besonders flexible und weitgehende 
Erweiterbarkeit zu ermoglichen. Insbesondere soil die Funk- 
tionalitat einer Komponente verandert und/oder erweitert 
werden konnen, ohne dali dazu Kenntnisse des Source-Codes der 

35 zu erweiternden Komponente erforderlich sind. 
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Erf indungsgemail wird diese Aufgabe durch ein Programmablauf - 
verf ahren bei einem Programmkomponentensystem mit den Merk- 
malen des Anspruchs 1 sowie durch ein Verfahren zur Erweite- 
rung des Programmkomponentensystems mit den Merkmalen des 
5 Anspruchs 10 gelost. 
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Im folgenden wird die zu erweiternde Komponente als "Grund- 
komponente" und die neu hinzuzuf iigende Komponente als "Er- 
weiterungs komponente " bezeichnet . 

10 

Die Erfindung geht von der Grunduberlegung aus, eine nahezu 
beliebige Erweiterbarkeit der Grundkomponente dadurch zu 
erzielen, daft auf das Erfordernis einer vom Programmierer 
definierten Erweiterungsschnittstelle in der Grundkomponente 
15 verzichtet wird. Vielmehr legt der Produzent der Erweite- 

rungskomponente fest, wie die Erweiterungskomponente mit der 
Grundkomponente zusammenwirken soil. Diese Grundidee stellt 
eine Umkehrung der bisher in der Informatik liblichen Prinzi- 
pien (encapsulation, information hiding, ... ) dar. Oberra- 
20 schenderweise lassen sich jedoch gerade durch diese Abkehr 

von etablierten Grundsatzen relativ groiie Sof twaresysteme in 
erstaunlich kurzer Zeit auch durch Nicht-Programmierer 
realisieren. 

fe5 Die erf indungsgemafie Uberlegung, die Erweiterungsschnitt- 
stellen nicht durch den Programmierer der Grundkomponente, 
sondern durch den der Erweiterungskomponente festlegen zu 
lassen, bedingt eine Umkehr von gewohnten Denkweisen wahrend 
des Programmablauf s sowie wahrend des Einbindens einer Er- 

30 weiterungskomponente in ein bestehendes Programmkomponenten- 
system. Diese beiden Falle sind Gegenstand der nebengeordne- 
ten Anspruche 1 und 10. 

Wahrend des Programmablauf s benotigen Komponenten ublicher- 
35 weise Daten voneinander, um sie zu verarbeiten und Ergeb- 

nisse zu erzeugen. Es ist bekannt, eine aufgerufene Prozedur 
von der aufrufenden Stelle mit Daten zu versorgen und die 
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Ergebnisse beim Riicksprung zuruckzugeben. Dieses Verfahren 



grammierer der aufrufenden Prozedur vordefiniert ist. 

Erf indungsgemaB ist dagegen vorgesehen, dafl sich die aufge- 
rufene Komponente - iiber ein geeignetes Lauf zeitsystem - die 
benotigten Daten selbst beschafft. Dieser Vorgang wird im 
folgenden als "Datenbesorgung" bezeichnet. In der Komponen- 
te, von der Daten besdrgt werden, miissen keine besonderen 
Schnittstellen vom Programmierer festgelegt worden sein. 
Entsprechend ist es eine Aufgabe der aufgerufenen Komponen- 
te, die Ergebnisse an geeignete Stellen anderer Komponenten 
einzuspeichern. Dieser Vorgang wird als "Datenentsorgung" 
bezeichnet. Auch hier ist es nicht erf orderlich, daJi der 
Programmierer besondere Schnittstellen fur die Datenentsor- 
gung vorgesehen hat. In diesem Zusammenhang soil die blofie 
Definition oder Deklaration eines Datenfeldes oder einer 
Variablen (gegebenenf alls einschlielilich einer Typangabe und 
weiterer Parameter) nicht als eine "Schnittstelle" angesehen 
werden. Eine Schnittstelle waren dagegen zum Beispiel proze- 
durale Anweisungen, die vom Programmierer explizit in ein 
Komponentenskript eingefiigt werden miissen, urn ztir Laufzeit 
einen Datentransf er zu veranlassen oder zu ermoglichen. 

Beim Anbinden einer Erweiterungskomponente an ein bestehen- 
des Programmkomponentensystem werden die bekannten Prinzi- 
pien in entspre.chender Weise umgekehrt. Normalerweise wurde 
man erwarten, daft die bisherigen Komponenten des Programm- 
komponentensystems durch die Erweiterung unverandert blei- 
ben. Erf indungsgemaB ist dagegen vorgesehen, im Programm- 
komponentensystem nach Andockpunkten fur die Erweiterungs- 
komponente zu suchen, und diejenigen Komponenten des Pro- 
grammkomponentensystems, in denen mindestens ein Andockpunkt 
gefunden wurde, zu andern, indem an jedem gefundenen Andock- 
punkt eine Aufruf information auf die neue Komponente einge- 
tragen wird. Es wird also potentiell jede Komponente des 
gesamten Programmkomponentensystems verandert. 



setzt jedoch voraus, daft die Auf ruf schnittstelle vom Pro- 
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Durch die erf indungsgemafle Losung wird es moglich, weitge- 
hende Erweiterungen der Funktionalitat eines Programmkompo- 
nentensystems durchzuf uhren, ohne dafi solche Moglichkeiten 
5 vom Programmierer der bisherigen Komponenten bereits ge- 
plant, vorgesehen oder vorgedacht sein mufJten. Dies stellt 
einen wesentlichen Fortschritt gegenuber den bisher bekann- 
ten Programmkomponeritensystemen dar. 

10 Unter dem Begriff "Lauf zeitsystem" werden in der Wortwahl 
dieser Anmeldung insbesondere alle generischen Routinen 
verstanden; also solche Routinen, die nicht vom Programmie- 
rer einer Komponente explizit vorgegeben werden. Hierbei 
kann das Lauf zeitsystem auch Anteile aufweisen, die in den 
15 Komponenten enthalten sind. Beispielsweise kann derjenige 

Teil des Lauf zeitsystems , der den Datentransf er vornimmt, in 
die einzelnen Komponenten verlagert sein. 

Die bei der Datenbe- und -entsorgung ubermittelten Daten 
20 sind bevorzugt nicht allgemein zuganglich, sondern derjeni- 
gen Komponente zugeordnet, von der die Daten besorgt bezie- 
hungsweise in die sie entsorgt werden. Diese Daten werden in 
bevorzugten Ausf uhrungsf ormen ubertragen, wahrend die ge- 
nannte Komponente inaktiv ist. Insbesondere kann diese Kom- 
15 ponente zum Zeitpunkt der Datenbe- und -entsorgung aus dem 

regularen Arbeitsspeicher ausgelagert sein. Bevorzugt werden 
bei der Datenbe- und/oder -entsorgung lokale und/oder nicht- 
persistente Daten iibermittelt, also insbesondere keine 
global verfiigbaren Daten. 

30 

Bevorzugt erfolgt die Datenbe- und/oder -entsorgung ohne 
Mitwirkung der. Komponente, von der die Daten besorgt bezie- 
hungsweise in die, sie entsorgt werden. Beispielsweise kann 
vorgesehen sein, bei einer Datenentsorgung lediglich die 
35 entsorgende Komponente sowie das Lauf zeitsystem zu beteili- 
gen. Diejenigen Komponente, in die die Daten abgelegt wer- 
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den, hat in bevorzugten Ausf uhrungsf ormen keine Einfluiimog- 
lichkeit. 

Vorzugsweise werden beim Ausfiihren einer Komponente diejeni- 
5 gen Datenf elder vorgemerkt, fur die eine Datenentsorgung 

erforderlich ist. Dies konnen insbesondere Datenf elder sein, 
deren Inhalte durch eine Datenbesorgung ermittelt wurderi und 
auf die ein Schreibzugrif f erfolgt ist. 

10 Bevorzugt ist ferner vorgesehen, dali eine aufgerufene Kompo- 
nente unmittelbar auf in der aufrufenden Komponente defi- 
nierte und/oder verfiigbare Datenfelder lesend und schreibend 
zuzugreifen vermag. Dies ermoglicht einen quasi schnittstel- 
lenfreien Datenaustausch zwischen denbeiden genannten Kom- 
15 ponenten. Der Aufruf einer Komponente wird vorzugsweise 

durch eine in einem Andockpunkt der aufrufenden Komponente 
enthaltene Auf ruf information oder -nachricht ausgelost. Die 
Verwendung von Andockpunkten, die Auf ruf inf ormationen auf- ' 
nehmen konnen, ermoglicht eine besonders flexible Funktio- 
20 nalitatserweiterung. 

Als potentielle Andockpunkte sind bevorzugt alle Interak- 
tionsschnittstellen einer Komponente vordefiniert . Solche 
Interaktionsschnittstellen konnen Interaktions-Bildschirm- 
f elder sein, zum Beispiel Eingabef elder oder Schaltf lachen . 
Ferner konnen alle Ausgabef elder einer Druckmaske und/oder 
alle Zugrif f soperationen auf persistente Daten (zum Beispiel 
Offnen, Lesen und Schreiben einer Datei oder einer Daten- 
bank) als Interaktionsschnittstellen vorgesehen sein. Inter- 
30 aktionsschnittstellen konnen in bevorzugten Ausf uhrungsf or- 
men auch vom Programmierer einer Komponente vorgegeben sein. 

Vorzugsweise werden bei dem Einbinden einer weiteren Kompo- 
nente in das Programmkomponentensystem alle moglichen An- 
35 dockpunkte automatisch (und ohne Kenntnis des Source-Codes 
der bereits vorhandenen Komponenten) identif iziert . Damit 
ist eine Erweiterung mit geringem Programmieraufwand mog- 
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lich. Ferner werden bevorzugt geeignete Auf ruf inf ormationen 
in mindestens einen Andockpunkt eingetragen. 



In bevorzugten Ausgestaltungen enthalt das -Verfahren zur 
5 Komponentenerweiterung den weiteren Schritt, mindestens eine 
Komponente als Binarobjekt zu erzeugen. Insbesondere kann 
fur jeden gefundenen Andockpunkt genau oder hochstens ein 
Binarobjekt generiert werden. In diesem Binarobjekt kann die 
Speicherzuteilung des Programmkomponentensystems zur spate- 
10 ren Laufzeit beriicksichtigt werden . 

Weitere bevorzugte Ausf iihrungsf ormen sind Gegenstand der 
Unteranspriiche . 

15 Ein Ausf uhruiigsbeispiel der Erfindung und mehrere Ausfuh- 

rungsvarianten werden im folgenden anhand der schematischen 
Zeichnungen genauer erlautert. 

Fig. 1 zeigt eine Prinzipdarstellung des Programmkomponen- 
20 tensystems wahrend der Laufzeit, 

Fig. 2 zeigt eine Prinzipdarstellung eines Binarobj ekts f 

Fig. 3 zeigt ein Flufidiagramm der Instantiierung von Kompo- 
^5 nenten, 

Fig. 4a bis Fig. 4c zeigen ein Flulidiagramm des Berechnungs- 
ablaufs zur Laufzeit einschlieBlich eines Komponentenwech- 
sels. 

30 

In Fig. 1 ist die Struktur des Programmkomponentensystems 
wahrend der Laufzeit veranschaulicht . Ein Betriebssystem 10, 
beispielsweise ein ubliches Fensterbetriebssystem, ist um 
eine Verteilerplattf ormschicht 12, zum Beispiel DCOM oder 
35 CORBA, erweitert. Auf die Verteilerplattf ormschicht 12 setzt 
ein Lauf zeitsystem 14 auf, das auch als "Middleware" be- 
zeichnet wird. Das Betriebssystem 10 stellt einen Arbeits- 
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speicherbereich 16 bereit, der von dem Lauf zeitsystem 14 
verwaltet und genutzt wird. In einer Ausf iihrungsvariante ist 
die Verteilerplattformschicht 12 weggelassen, und das Lauf- 
zeitsystem 14 setzt unmittelbar auf das Betriebssystem 10 
5 auf. Das Programmkomponentensystem wird von einem; handels- 
iiblichen Computer, beispielsweise von einem PC-kompatiblen 
Rechner, ausgefuhrt. 

Neben dem Lauf zeitsystem 14 weist das Programmkomponenten- 
10 system eine Containerumgebung 18 auf, die mehrere Komponen- 
ten 20, 20', 20'', 20''' in Form von Binarobjekten enthalt. 
Die Komponenten 20, 20 1 , 20' 2*0' ? ' bestimmen das Verhalten 
des Prograrnmkomponentensystems . Sie werden - beispielsweise 
in Abhangigkeit von Ereignissen, die der Benutzer auslost - 
15 von dem Lauf zeitsystem 14 aufgerufen. 

Eine Komponente 20 im Binarobj ekt format weist, wie in Fig. 2 
dargestellt, mehrere Abschnitte auf, und zwar einen Pro- 
grammabschnitt 22, einen Tabellenabschnitt 24, einen Ver- 
20 zeichnisabschnitt 26 und einen Speicherbildabschnitt 28. 

Der Programmabschnitt 22 enthalt interpretierbaren Code, der 
zur Laufzeit von dem Lauf zeitsystem 14 interpretiert wird 
und das Verhalten der Komponente 20 bestimmt. Der im Pro- 
grammabschnitt 22 enthaltene Code ist in einem Zwisohenfor- 
mat, das eine effiziente Ausfiihrung zur Programmlauf zeit er- 
laubt. In Ausf iihrungsalternativen ist eine geeignete Kompi- 
lierung des Codes zur unmittelbaren Ausfiihrung unter Kon- 
trolle des Betriebssystems 10 vorgesehen. 

30 

Im Tabellenabschnitt 24 sind Lauf zeittabellen fur konfigu- 
rierbare Eigenschaf ten und Parameter des Codes gespeichert. 
Dies sind beispielsweise Inf ormationen iiber Fenstergrolien 
und Farben fur die Bildschirmdarstellung oder Inf ormationen 
35 fur die Druckdarstellung. Auflerdem enthalten die Lauf zeit- 
tabellen Verwaltungsinf ormationen fur die Speicherzuteilung . 
Der Verzeichnisabschnitt 26 beinhaltet ein Verzeichnis der 
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Andockreferenzen, ein Speicherverzeichnis, ein Datentrans- 
ferverzeichnis und ein Methodenverzeichnis . 

Das Speicherverzeichnis enthalt die in der Komponente ver- 
5 fugbaren Bezeichnungen fur Speicherf elder, Inf ormationen zu 
den Speicherf eldern sowie Verweise (genauer gesagt, Offset- 
oder Displacementwerte) darauf. Das Methodenverzeichnis 
enthalt eine Liste der von der Komponente bereitgestellten 
Methoden. Diese beiden Verzeichnisse sind im Binarobjekt 
10 enthalten, damit auch ohne Kenntnis des Source-Codes einer 

Komponente (Komponentenskript ) eine Erweiterung der Funktio- 
nalitat einer Komponente moglich ist. Alle im Speicherver- 
zeichnis enthaltenen Speicherf elder sind durch die Operatio- 
nen der Datenbe- und -entsorgung von beliebigen anderen Kom- 
15 ponenten aus zuganglich und konnen gelesen, verandert und 

beschrieben werden. Der Programmierer hat im hier beschrie- 
benen Ausf uhrungsbeispiel keine Moglichkeit, einzelne Spei- 
cherf elder vor fremdem Zugriff zu schutzen. Inf ormationen, 
die bei der Laufzeit zur Datenbe- und -entsorgung benotigt 
20 werden, sind im Datentransf erverzeichnis enthalten. 

Im Speicherbildabschnitt 28 sind drei zusammenhangende Da- 
tenbereiche 30, 32, 34 vorgesehen, deren Grenzen durch die 
Verwaltungsinf ormationen in den Lauf zeittabellen angegeben 

K5 werden. Der erste Datenbereich wird im folgenden als Zu- 
griff sdatenbereich 30 bezeichnet. Er ist fur diejenigen Da- 
ten reserviert, die von einer innerhalb der Auf ruf hierarchie 
ubergeordneten Komponente stammen. Diese Daten kann die auf- 
gerufene Komponente unmittelbar lesen, verarbeiten und 

30 schreiben, ohne dali ein programmierter Datentransf er notwen- 
dig ware. Ubertragen auf eine prozedurale Programmiersprache 
entspricht dies ungefahr der Moglichkeit, unmittelbar auf 
Variablen zuzugreifen, die in einer statisch ubergeordneten 
Prozedur definiert sind. Die Grofte des Zugriff sdatenbereichs 

35 30 wird bei der Instantiierung einer Komponente 20 festge- 
legt. Dies ist moglich, weil jede Komponente 20 im Binarob- 
jekt format nur genau einer moglichen Aufrufstelle (einem An- 
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dockpunkt) zugeordnet ist. Die GroJie des Zugrif fsdatenbe- 
reichs 30 einer Komponente 20 ist die Summe der Grofien des 
Zugrif fsdatenbereichs und des (noch zu beschreibenden) Lo- 
kaldatenbereichs der aufrufenden Komponente. 

5 

Als zweiter Datenbereich im Speicherbildabschnitt 28 einer 
Komponente 20 ist der Lokaldatenbereich 32 vorgesehen. Die- 
ser Datenbereich schlieiit unmittelbar an den Zugrif fsdaten- 
bereich 30 an. Er enthalt diejenigen Daten, die in der 

10 Komponente 20 neu definiert werden. Eine solche Definition 
kann unmittelbar in der Komponente oder indirekt - zum Bei- 
spiel durch eine Referenz auf eine Bildschirmmaske oder ein 
Druckformat - erfolgen. Obertragen auf eine prozedurale Pro- 
grammiersprache enthalt der Lokaldatenbereich 32 ungefahr 

15 die lokalen Variablen einer Prozedur. 

Schlieftlich ist als dritter Datenbereich im Speicherbild- 
abschnitt 28 ein Transf erdatenbereich 34 vorgesehen. Der 
Transf erdatenbereich ist zur Zwischenspeicherung von Daten 
20 reserviert, die wahrend der Programmlauf zeit von einer an- 

deren Komponente nach dem Datenbesorgungsprinzip besorgt und 
nach dem Datenentsorgungsprinzip in diese entsorgt werden. 



» 



Wenn eine Komponente 20 instantiiert , also aus einem Kompo- 
nentenskript in mindestens ein Binarobjekt iibersetzt wird, 
brauchen der Zugrif fsdatenbereich 30 und der Transf erdaten- 
bereich 34 nicht mit definierten Werten belegt zu werden, 
weil diese Bereiche zur Lauf zeit sowieso uberschrieben wer- 
den. Der Lokaldatenbereich 32 wird mit vorgegebenen Stan- 
30 dardwerten fur die einzelnen Datentypen gefullt. Wahrend der 
Laufzeit eines Programmkomponentensystems dienen die drei 
Datenbereiche 30, 32 und 34 einer Komponente 20 zur Zwi- 
schenspeicherung des jeweils aktuellen Systemzustandes bei 
jedem Aufruf einer weiteren Komponente und zum teilweisen 
35 Wiederherstellen dieses Zustandes (hinsichtlich des Lokal- 

datenbereichs 32 und des Transf erdatenbereichs 34) bei einem 
Rucksprung. 



acOlde 
ACQS . , 



• • • • 



• • • * 

• . • * 

• • • 

• • • • • • 



11 



Zur Erzeugung einer Komponente erstellt der Programmierer 
ein Komponentenskript , das zur automatischen Obersetzung 
mittels eines Generator'systems geeignet ist. Dieser auch als 
5 Instantiierung einer Komponente bezeichnete Obers;etzungsvor- 
gang wird unten genauer beschrieben. Das Komponentenskript 
stellt die Definition der zu generierenderi Komponente dar. 
Es enthalt Anweisungszeilen, die als interpretierbarer Code 
der Komponente iibersetzt werden. Die verwendete Programmier- 
10 sprache ist an sich bekannt und beruht auf objektorientier- 
ten Prinzipien. Aufierdem kann das Komponentenskript Anwei- 
sungszeilen enthalten, die vom Programmierer vorgedachte An- 
dockpunkte fiir Erweiterungen bestimmen. Optional konnen auch 
Daten und Parameter in einem Komponentenskript enthalten 
15 sein, zum Beispiel Parameter fiir die visuelle Darstellung 
von Daten oder eine Aufzahlung zulassiger Eingabewerte . 
Weiter konnen im Komponentenskript Anweisungen zum Aufruf 
von "Fremdprogrammen" enthalten sein. Wahrend der Laufzeit 
wird danri das entsprechende Programm, beispielsweise ein 
20 COBOL-Programm, gestartet. Dieses Programm kann nunsei- 

nerseits Schnittstellen des Programmkomponentensystems nut- 
zen und beispielsweise weitere Komponenten starten. 

Ferner kann das Komponentenskript Referenzen auf zu verwen- 
■ 5 dende Bildschirmmasken und -formate sowie auf. Druckformate 
^ enthalten. Solche Bildschirmmasken oder Druckformate werden 
vorab mittels eines geeigneten graphischen Werkzeugs ent- 
wickelt. Das Werkzeug ("GUI-Builder") erzeugt mehrere globa- 
le Verzeichnisse, auf die wahrend jedes Instantiierungsvor- 
30 gangs einer Komponente zugegriffen wird. Dies sind erstens 
ein globales Verzeichnis der verfiigbaren Bildschirmmasken 
und Druckformate, zweitens ein Verzeichnis der durch diese 
Masken und Formate vorgegebenen Andockpunkte und drittens 
ein Verzeichnis der Bezeichner und Typen der in den defi- 
35 nierten Eingabef eldern beziehungsweise Druckfeldern erwar- 
teten Daten. 
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Falls es sich bei dem Komponentenskript urn die Definition 
einer Erweiterungskomponente handelt, also einer Komponente,. 
die eine bereits bestehende Komponente (Grundkomponente) er- 
weitern soil, enthalt das Komponentenskript ferner einen 
5 Vererbungsparameter, der die gewunschten Andockpunkte fur 

die Komponentenerweiterung spezif iziert Der Vererbungspara- 
meter kann, wie noch erlautert wird, mehr als eine Grundkom- 
ponente und mehr als einen Andockpunkt definieren. 

0 Als Andockpunkte dienen generische oder vom Programmierer 
angegebene Stellen der Grundkomponente, an denen _eine Auf- 
ruf information fur eine Erweiterungskomponente eingefugt 
werden kann. Die Andockpunkte einer Komponente im Binar- 
objektformat konnen automatisch identif iziert werden, so daft 

5 eine Komponentenerweiterung ohne Kenntnis des Source-Codes 
der Grundkomponente moglich ist. 

Im hier beschriebenen Ausf tihrungsbeispiel sind vier Arten 
von Andockpunkten vorgesehen. Erstens sind als Andockpunkte 
0 alle Eingabef elder und sonstige Bedienelemente (Knopfe, 

Schaltf lachen, . . . ) in den Bildschirmmasken vorgesehen, auf 
die die Grundkomponente zugreift. Damit ist es zum Beispiel 
moglich, Komponentenerweiterungen immer dann aufzurufen, 
wenn der Benutzer eine Interaktion mit einem Eingabefeld der 
Grundkomponente durchfiihrt, beispielsweise einen Wert ein- 
gibt oder das Eingabefeld aktiviert oder mit dem Mauszeiger 
iiberfahrt. Der Programmierer der Grundkomponente braucht 
diese Moglichkeit nicht explizit vorzusehen. Ebenso dienen 
alle Druckmasken-Ausgabef elder als Andockpunkte, so daft bei- 
0 spielsweise durch eine Komponentenerweiterung die Ausgabe- 
werte einer auszudruckenden Tabelle verandert werden konnen. 

Als Andockpunkte sind ferner alle Operationen der Grundkom-. 
ponente auf persistente Daten (beispielsweise Datei- oder 
5 Datenbankzugrif f e) vorgesehen. Auch hier konnen Erweite- 

rungskomponenten " zwischengeschaltet " werden, ohne dafi dies 
der Programmierer der Grundkomponente ausdriicklich angeben 
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miifite. Schlieiilich kann, wie bereits erwahnt, eine Komponen- 
te auch vom Programmierer bestimmte Andockpunkte an beliebi- 
gen Stellen des Programmablauf s enthalten. In Ausfiihrungs- 
alternativen sind weitere oder andere Andockpunkte moglich. 

5 ; . 

Jeder Andockpunkt weist in dem hier beschriebenen Ausfiih- 
rungsbeispiel mehrere Andockstellen ("slots") auf. Dadurch 
konnen mehrere Komponentenerweiterungen an einen einzigen 
Andockpunkt angeschlossen werden. Bei einem Andockpunkt, der 

0 einem Eingabefeld zugeordnet ist, sind beispielsweise eine 
Haupt-Andockstelle und fiinf Neben-Andockstellen vorgesehen. 
Eine eventuell in der Haupt-Andockstelle eingetragene Kompo- 
nentenerweiterung wird immer dann aufgerufen, wenn der Be- 
nutzer das Eingabefeld aktiviert. Wahlweise kann diese Kom- 

5 ponente auch bei jedem Anzeigen des Eingabef eldes , also 
schon vor einer Benutzeraktion, aufgerufen werden. Die 
Neben-Andockstellen konnen dagegen zum Beispiel dem Betati- 
gen bestimmter Funktionstasten oder anderen Aktionen des 
Benutzers zugeordnet werden. Bei Druckmasken-Ausgabef eldern 

0 kann die Ansteuerung der Andockstellen eines Andockpunktes 
zum Beispiel durch eine Bedienereingabe zum Startzeitpunkt 
des Druckvorgangs bestimmt werden. In Ausf iihrungsalternati- 
ven sind andere Auf ruf strategien oder andere Anzahlen von 
Andockstellen (beispielsweise nur eine pro Andockpunkt) 

5 moglich. 

Im folgenden wird die Instantiierung von Komponenten unter 
Hinweis auf Fig. 3 genauer beschrieben. Wie bereits erwahnt, 
bedeutet Instantiierung die Obersetzung eines Komponenten- 
0 skripts in mindestens ein Binarobjekt. Im hier beschriebenen 
Ausf iAhrungsbeispiel wird bei der Instantiierung fur jeden 
gefundenen Andockpunkt genau eine Komponente als Binarobjekt 
erzeugt. 

5 Der Instantiierungsvorgang, der automatisch von dem Genera- 
torsystem durchgefuhrt wird, beginnt mit dem Einlesen des 
Komponentenskripts. (Schritt 40). In Schritt 42 wird nun. ein 
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erster Andockpunkt gesucht. Wenn das zu tibersetzende Kompo- 
nentenskript nur die Containeridentif izierung als Verer- 
bungsparameter enthalt, wird ein generischer Andockpunkt in 
der Containerumgebung 18 (Fig. 1) angenommen. Dies ermog- 
5 licht eine Instantiierung von "Wurzelkomponenten 1 ^ also Kom- 
ponenten, die keine Komponentenerweiterungen darstellen. 

Enthalt dagegen das zu tibersetzende Komponentenskript einen 
"echten" Vererbungsparameter, so definiert dieser die fur 

0 die Komponentenerweiterung vorgesehenen Andockpunkte. Hier- 
fiir bestehen mehrere Moglichkeiten . Wenn zum Beispiel ein 
Eingabefeld einer Bildschirmmaske als Andockpunkt dienen 
soil, so kann der Vererbungsparameter sowohl den Feldnamen 
und die gewunschte Andockstelle innerhalb des Andockpunktes 

5 (Nummer des "slots") angeben als auch die Grundkomponente 
spezif izieren. Alternativ ist es auch moglich, im Verer- 
bungsparameter nur den Feldnamen und gegebenenf alls die Num- 
mer des "slots" einzutragen. Als Andockpunkte dienen dann 
alle Stellen in den gegenwartig im Programmkomponentensystem 

0 vorhandenen Binarob j ekten, an denen ein Bildschirmf ormat re- 
f erenziert Vird, das das genannte Feld als Eingabefeld ver- 
wendet. 

Wenn ein erster Andockpunkt gefunden wurde (Abfrage 44), so 
5 wird zunachst eine geeignete Aufruf information, beispiels- 
weise eine zum Aufruf der Erweiterungskomponente dienende 
Nachricht ("message"), in die den Andockpunkt enthaltende 
Grundkomponente eingetragen (Schritt 4 6) . Die Grundkomponen- 
te wird dazu im Binarob jektf ormat gelesen, der Verweis auf 
0 die Erweiterungskomponente wird in die Grundkomponente ein- 
getragen, und das so veranderte Binarob jekt wird in das Pro- 
grammkomponentensystem zuriickgeschrieben . Der Vererbungs- 
parameter legt dabei fest, an welcher Andockstelle ("slot") 
innerhalb eines Andockpunktes die Auf ruf information einge- 
5 tragen werden soil und welche Benutzeraktion zu einem Aufruf 
der Erweiterungskomponente fuhren soil. 
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Nach der Modif if kation der den gefundenen Andockpunkt ent- 
haltenden Grundkomponente, wird die diesem Andockpunkt zuge- 
ordnete Erweiterungskomponente als Binarobjekt aufgebaut 
(Kasten 48) . Zunachst werden die Andockpunkte der Erweite- 
5 rungs komponente bestimmt und in das entsprechende; Verzeich- 
nis im Verzeichnisabschnitt 26 der Komponente 20 eingetragen 
(Schritt 50) . Dazu werden alle Bildschirmmasken und Druck- 
formate untersucht, auf die das Skript der Erweiterungskom- 
ponente verweist. Ferner erfolgt ein Zugriff auf das globale 

10 Verzeichnis der durch diese Masken und Formate definierten 
Andockpunkte. Die dort enthaltenen Inf ormationen werden als 
Andockref erenzen in den Verzeichnisabschnitt 26 ubernommen. 
Neben dem Namen eines eingebundenen Bildschirm- oder Druck- 
feldes sind dies beispielsweise Inf ormationen uber den Feld- 

15 typ, den Speicherplatzbedarf des zugeordneten Datenwertes 
und so weiter. 

Ferner wird das Komponentenskript nach Andockref erenzen 
durchsucht, die vom Programmierer angegeben wurden (Kon- 
20 strukt INTERFACE-IS <Name>) . Auch diese Andockref erenzen 

werden in den Verzeichnisabschnitt 26 ubernommen. Schliefi- 
lich werden auch fur alle im Komponentenskript gefundenen 
Zugriff soperationen auf persistente Daten (Konstrukt zum 
Beispiel READ <Entitatsname>) entsprechende Andockref erenzen 
in den Verzeichnisabschnitt 26 aufgenommen. 

In einem nachsten Schritt 52 wird die Lauf zeit-Speicherorga- 
nisation instantiiert . Hierzu werden zunachst diejenigen 
Feldbezeichnungen in den von der Erweiterungskomponente re- 
30 ferenzierten Bildschirmmasken und Druckf ormaten bestimmt, 
die nicht bereits in der Grundkompohente definiert sind, 
Diese Feldbezeichnungen werden - sofern sie nicht mit Ein- 
tragen im Zugriff sdatenbereich 30 ubereinstimmen - als loka- 
le Variablen der Erweiterungskomponente angesehen. Alle 
35 Feldbezeichnungen werden in das Speicherverzeichnis im Ver- 
zeichnisabschnitt 2 6 eingetragen. Ferner wird eine Transfer- 
liste angelegt, urn wahrend der Laufzeit die Bildschirm- und 
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Druckdaten aus einem Puf f erspeicher in den Speicherbereich 
der Erweiterungskomponente (Zugrif f sdatenbereich 30 oder 
Lokaldatenbereich 32 oder Transf erdatenbereich 34) zu uber- 
tragen. Diese Funktion wird zur Laufzeit automatisch aus- 
5 gefiihrt, ohne daft eine explizite Programmierung erforderlich 
ware. 

Als weiterer Teil des Schritts 52 werden nun die statischen 
Speicherdef initionen im Komponentenskript verarbeitet. Da 
10 die Grundkomponente eindeutig feststeht, konnen schon zur 
Instantiierungszeit die Groften der drei Datenbereiche 30 , 
32, 34 des Binarobjekts 20 ermittelt werden. Ferner kann das 
Speicherverzeichnis im Verzeichnisabschnitt 26 vollstandig 
erstellt werden. 
15 

Zunachst werden alle diejenigen statischen Speicherdef ini- 
tionen (Konstrukt INHERIT- DATA <Name>) im Komponentenskript 
gesucht, die bereits in der Grundkomponente definiert sind. 
Die entsprechenden Datenwerte finden sich zur Laufzeit im 

20 Zugrif f sdatenbereich 30 an der gleichen Stelle (dem gleichen 
Versatz- oder Displacementwert ) wie bei der Grundkomponente, 
da der Arbeitsspeicherbereich 16, der vom Zugrif f sdatenbe- 
reich 30 der Grundkomponente belegt wird, beim Aufruf der 
Erweiterungskomponente weiterverwendet wird. In das Spei- 

|5 cherverzeichnis der Erweiterungskomponente werden daher Ein- 
trage aufgenommen, die denen der Grundkomponente entspre- 
chen. Diese Eintrage enthalten den Namen und Typ des Daten- 
wertes sowie die Feldlange und den Displacementwert. 

30 Schlieftlich werden solche statische Speicherdef initionen des 
Komponentenskripts verarbeitet, die dem Lokaldatenbereich 32 
zugeordnet sind. Dies sind erstens Definitionen von Spei- 
cherfeldern, die in der Grundkomponente nicht definiert 
sind, und zweitens Speicherdef initionen, bei denen ausdruck- 

35 lich eine lokale Speicherung angegeben wurde (Konstrukt 

INHERIT -DATA-LOCAL <Name>) . Fur derartige Speicherdef ini- 
tionen wird eine freie Adresse im Lokalspeicherbereich 32 
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ermittelt und reserviert. Genauer gesagt, wird die nachste 
freie Adresse hinsichtlich des aktuellen Speicherpegels (der 
von der Speicherbelegung der Grundkomponente und eventuell 
schon zugewiesenen lokalen Feldern der Erweiterungskomponen- 
te abhangt) verwendet. Auch fur diese Speicherdef initionen 
werden entsprechende Eintrage in das Speicherverzeichnis der 
Erweiterungskomponente auf genommen . 

Als nachster Schritt 54 wird die zur Laufzeit stattf indende 
Datenbe- und -entsorgung der Erweiterungskomponente instan- 
tiiert, indem das Datentransf erverzeichnis im Verzeichnis- 
abschnitt 26 angelegt wird. Hierzu werden zunachst die 
Datenbe- und -entsorgungsdef initionen im Komponentenskript 
gesucht. Diese Def initionen haben die folgende Form, wobei 
INH fur "inherit" und "IME" fur "Import/Export" steht: 

INH-DATA-IME <Identif ikation der Komponente, mit der 

die Datenbe- und -entsorgung stattfindet> 
INTERFACE = <Feldname_l>, 
<Feldname__2>, 
• . . i 

<Feldname_n> 

ENDTRANSFER 

Beim Auffinden einer derartigen Definition wird das Spei- 
cherverzeichnis der adressierten Komponente ausgewertet. In- 
formationen iiber die auszutauschenden Datenfelder (Feldtyp, 
Feldlange, Adresse oder Displacement) im Arbeitsspeicherbe- 
reich 16 zur Laufzeit werden eingelesen. Ferner wird ein 
entsprechendes Speicherfeld im Transf erdatenbereich 34 re- 
serviert, sofern das adressierte Feld nicht im Zugriffsda- 
tenbereich 30 enthalten ist. Aus diesen Inf ormationen wird 
ein entsprechender Eintrag im Datentransf erverzeichnis des 
Verzeichnisabschnitts 2 6 der Erweiterungskomponente erzeugt. 
Dieser Eintrag enthalt somit die Zuordnung des Speicherfel- 
des der adressierten Komponente zu dem Speicherfeld im 
Transf erdatenbereich 34 der gegenwartig instantiierten Kom- 
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ponente. Die adressierte Komponente braucht nicht die Grund- 
komponente zu sein, und das adressierte Speicherfeld in die- 
ser Komponente kann in einem der drei Bereiche 30, 32 und 34 
liegen. Demgemafi ist eirie Datenbe- und -entsorgung von alien 
5 Daten moglich, die in einer beliebigen anderen Komponente 
verfugbar sind. 

Nun erfolgt die Codegenerierung (Schritt 56) , in der die An- 
weisungszeilen im Komponentenskript in einen geeigneten, von 
10 dem Lauf zeitsystem 14 interpretierbaren Zwischencode umge- 
setzt werden. Die Codegenerierung wird nach an sich bekann- 
ten Grundsatzen ausgefiihrt. Die Komponente wird nun im Bi- 
narobjektf ormat aus den Bestandteilen zusammengebunden, die 
bei den bisher beschriebenen Schritten erzeugt worden sind. 
15 Das resultierende Binarobjekt hat die in Fig. 2 gezeigte und 
oben bereits beschriebene Struktur. Es wird in einem weite- 
ren Schritt gespeichert (Schritt 58) . 

Damit ist die Erzeugung eines Binarobjekts fur einen Andock- 
20 punkt abgeschlossen. Im Instant iierungsverf ahren wird nun 
ein nachster Andockpunkt gesucht (Schritt 60) . Falls ein 
solcher im Programmkomponentensystem vorhanden ist, wird ein 
weiteres Binarobjekt erzeugt; andernfalls ist die Instanti- 
ierung beendet. Die aus einem Komponentenskript erzeugten 
k> Binarobjekte unterscheiden sich hochstens hinsichtlich der 
^ in dem Speicherverzeichnis definierten Speicherbelegung. 

Wenn in einer Grundkomponente mehrere Andockpunkte gefunden 
werden, ist diese Speicherbelegung jedoch im Regelfall iden- 
tisch. Dieser Fall kann auch eintreten, wenn mehrere Andock- 
30 punkte in verschiedenen Grundkomponenten gefunden werden. In 
einer Ausf uhrungsalternative ist daher zur Optimierung vor- 
gesehen, identische Binarobjekte nur je einmal zu erzeugen. 

Zum Ausflihren des Programmkomponentensystems wird die in 
35 Fig. 1 dargestellte Struktur aufgebaut. Dazu werden zunachst 
das Lauf zeitsystem 14 und die Containerumgebung 18 geladen 
und gestartet. Die Containerumgebung 18 enthalt einen Kata- 
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log der beim Starten sichtbaren Menlieintrage . Dieser Katalog 
wird durch die Komponenten 18 definiert. Nun wird eine Wur- 
zelkomponente gestartet, die bei dem oben beschriebenen In- 
stantiierungsvorgang von dem Generatorsystem eigenstandig 
5 erzeugt wurde. Das Lauf zeitsystem wartet nun auf ;ein vom 

Benutzer ausgelostes Ereignis, beispielsweise eine Meniiaus- 
wahl, durch das der Aufruf einer "eigent lichen" Komponente 
des Programmkomponentensystems angezeigt wird. 

10 In Fig. 4a bis Fig. 4c ist das Programmablauf verf ahren ge- 
zeigt, das beim Komponentenauf ruf sowie beim Ausfuhren der 
aufgerufenen Komponente durchgefuhrt wird. Zur Laufzeit ist 
in dem hier betrachteten Ausf lihrungsbeispiel stets genau 
eine Komponente aktiv. Unmittelbar nach dem Systemstart ist 

15 dies die oben beschriebene Wurzelkomponente . Nur die jeweils 
aktive Komponente befindet sich im Arbeitsspeicherbereich 
16. Die Komponente hat hierbei die in Fig. 2 gezeigte Binar- 
obj ektstruktur . In Ausf iihrungsalternativen ist auch ein 
quasi-paralleler Ablauf mehrerer Komponenten (z.B. uber 

20 "multi-threading") moglich. Die Steuerung erfolgt dann durch 
das zugrundeliegende Betriebssystem 10. 

Wenn eine neue Komponente aufgerufen werden soli, zum Bei- 
spiel in Reaktion auf eine Eingabe oder Aktion des Benut- 

|2 5 zers, wird zunachst der Zustand der gerade aktiven Komponen- 
te gesichert (Schritt 70) . Dies bedeutet zumindest, dafi der- 
jenige Teil des Arbeitsspeicherbereichs 16 in eine Datei 
oder einen sonstigen Sicherungsbereich iibertragen wird, in 
dem sich der Speicherbildabschnitt 28 der Komponente befin- 

30 det. Im hier beschriebenen Ausf lihrungsbeispiel wird sogar 
das gesamte Binarobjekt gesichert, weil dessen iibrige Ab- 
schnitte hinsichtlich des Speicherbedarf s nicht ins Gewicht 
fallen. 

35 Ferner werden alle Datenentsorgungsvorgange durchgefuhrt, 

die wahrend des Ablaufs der bisher aktiven Komponente vorge- 
merkt worden sind (Schritt 72) . Zur Ef f izienzsteigerung ist 
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in dem hier beschriebenen Ausf iihrungsbeispiel namlich vorge- 
sehen, nur diejenigen Speicherf elder des Transf erdatenbe- 
reichs 34, auf die ein schreibender Zugriff stattgefunden 
hat, wieder von der aktuellen Komponente in die durch die 
5 Datenentsorgung ref erenzierte Komponente zu iibertragen. In 
Ausf uhrungsalternativen erfolgt keine Vormerkung der veran- 
derten Daten, sondern es werden bei jedem Komponentenwechsel 
alle Datenfelder im Transf erdatenbereich 34 an die jeweils 
ref erenzierten Komponenten ubertragen. 

10 

Bei jedem Datenentsorgungsvorgang wird das Datentransf erver- 
zeichnis der aktuellen Komponente herangezogen, urn die refe- 
renzierte(n) Komponente (n) und das entsprechende Datenfeld 
(die entsprechenden Datenfelder) in deren Speicherbildab- 
15 schnitt(en) 28 zu bestimmen und die Daten dorthin zu uber- 
tragen- Durch jede Datenentsorgung wird somit ein Binarob- 
jekt einer gegenwartig nicht aktiven Komponente verandert. 
Wahrend der Laufzeit kann eine Komponente mehrmals aufgeru- 
fen und teilweise ausgeflihrt worden sein. In diesem Fall 
2 0 sind mehrere Versionen der Komponente gesichert. Die Daten- 
entsorgung findet in diesem Fall in diejenige gesicherte 
Komponentenversion statt, die innerhalb der zur gegenwartig 
aktiven Komponente flihrenden Aufrufkette dieser Komponente 
am nachsten steht. In Ausf uhrungsalternativen wird eine an- 
K5 dere oder vom Programmierer bestimmte Auswahl der zu verwen- 
~ denden Komponentenversion getroffen. 

Als nachster Schritt 7 4 wird nun die neu aufgerufene Kompo- 
nente als Binarobjekt in den Arbeitsspeicherbereich 16 gela- 
30 den. Dabei wird auf jeden Fall der Teil des Arbeitsspeicher- 
bereichs 16, der fur die Programm-, Tabellen- und Verzeich- 
nisabschnitte 22, 24, 26 der alten Komponente benutzt wurde, 
iiber schr ieben . 

35 Auch der Lokaldatenbereich 32 des Speicherbildabschnitts 28 
der neuen Komponente wird in den Arbeitsspeicherbereich 16 
geladen. Damit sind beim Start der neuen Komponente alle 
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lokalen Daten mit definierten Standardwerten vorbesetzt. 
Derjenige Abschnitt des Arbeitsspeicherbereichs 16, der dem 
Zugrif f sdatenbereich 30 der aufgerufenen Komponente ent- 
spricht, wird jedoch nicht uberschrieben. Damit gehen die 
5 dort gespeicherten Datenwerte beim Komponentenwectisel nicht 
verloren. Die neue Komponente kann vielmehr liber den Zu- 
grif f sdatenbereich 30 unmittelbar auf Speicherf elder zugrei- 
fen, die in der aufrufenden Komponente definiert sind.Die 
GroBe das Zugrif fsdatenbereichs 30 bestimmt sich nach der in 
10 der Instantiierungsphase ermittelten Speicherverteilung . 
Falls die aufrufende Komponente auf vollig andere Werte 
zugreift wie die aufgerufene Komponente, hat der Zugriffs- 
datenbereich 30 die Grolie Null. 

15 Nachdem die aufgerufene Komponente als Binarobjekt geladen 
wurde, wird der im Programmabschnitt 22 enthaltene Code 
Befehl fur Befehl interpretiert . Bei der Ausfiihrung eines 
Befehls (Schritt 76) sind einige Sonderfalle zu beachten. 

20 Falls es sich bei dem Befehl urn eine Speicheroperation han- 
delt, deren Ziel der Transf erdatenbereich 34 ist (Abfrage 
78), dann wird das betroffene Speicherfeld fur eine spatere 
Datenentsorgung vorgemerkt (Schritt 80) . Ein solches Vormer- 
ken ist auch durch einen ausdriicklichen Befehl moglich. 

v Handelt es sich bei dem aktuellen Befehl urn eine Anweisung, 
die. eine Datenbesorgung aus einer ref erenzierten Komponente 
veranlaiit (Abfrage 82) , so werden die in Fig. 4b gezeigten 
Schritte ausgefuhrt. Ein derartiger Befehl ist zum Beispiel 

30 das oben bereits beschriebene Konstrukt I NH- DATA- I ME , das im 
hier beschriebenen Ausf iihrungsbeispiel sowohl als Deklara- 
tion einer Datenbe- und -entsorgungsbeziehung als auch als 
Anweisung zur Datenbesorgung aufgefafit wird. In Ausfiihrungs- 
alternativen werden schon beim Start einer Komponente alle 

35 von dieser ref erenzierten Daten besorgt. 
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Bei dem Datenbesorgungsverf ahreh nach Fig. 4b wird zunachst 
gepriift, ob die ref erenzierte Komponente bereits (zumindest 
teilweise) ausgefuhrt wurde (Abfrage 84) . 1st dies nicht der 
Fall, so konnen keine gultigen Daten besorgt werden, und ein 

5 Lauf zeitf ehler wird ausgelost. Falls dagegen eine; gesicherte 
Version der ref erenzierten Komponente vorhanden ist, werden 
die benotigten Daten daraus geladen und in den Transfer- 
datenbereich 34 der gegenwartig aktiven Komponente geschrie- 
ben. Die jeweiligen Speicherplatze in der ref erenzierten und 

0 der aktiven Komponente sind aus dem Datentransf erverzeichnis 
der aktiven Komponente ersichtlich. Auch hier kann es (ahn- 
lich wie in Schritt 72) vorkommen, daft mehrere Versionen der 
ref erenzierten Komponente gespeichert sind. Es wird dann 
diejenige Version zur Datenbesorgung herangezogen, die in 

5 der zur aktiven Komponente fuhrenden Aufrufkette zuletzt 
ausgefuhrt wurde. In Ausf uhrungsalternativen sind andere 
vorgegebene oder programmierbare Auswahlstrategien moglich. 
Nach dem Ende der Datenbesorgung wird der Programmablauf bei 
Schritt 76 (Fig. 4a) fortgesetzt. 

0 

In Abfrage 88 (Fig. 4a) wird iiberpriift, ob es sich bei dem 
aktuell interpretierten Befehl um einen Befehl zum Komponen- 
tenwechsel, also zum Aufruf einer neuen Komponente, handelt. 
Ein solcher Befehl kann insbesondere eine in einem Andock- 

5 punkt gespeicherte Aufruf information (message) sein. Wie 

bereits beschrieben, fiihrt eine solche Aufruf information je 
nach der Art des Andockpunktes entweder durch ihr blofies 
Vorhandensein oder bei einer vorbestimmten Aktion des Benut- 
zers zum Aufruf der in der Aufruf information angegebenen 

0 Komponente. Wenn ein solcher Aufruf stattfindet, wird der 
aktuelle Bef ehlszahlerstand in einem Stapelspeicher gesi- 
chert und eine neue Instanz des in Fig. 4a dargestellten 
Verfahrens wird begonnen. 

5 Abfrage 90 betrifft schliefilich den Fall, dafl die Ausfiihrung 
der aktuellen Komponente regular beendet wird. Ist dies 
nicht der Fall, so wird die Programmausf iihrung mit Schritt 
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76 fortgesetzt. Falls dagegen das Programmende erreicht ist, 
wird das in Fig. 4c dargestellte Verfahren ausgefuhrt. Es 
werden zunachst, ahnlich wie in Schritt 72, alle vorgemerk- 
ten Datenentsorgungen ausgefuhrt (Schritt 92) . Daraufhin 

5 wird der Zustand derjenigen Komponente im Arbeitsspeicher- 
bereich 16 wiederhergestellt , die die aktuelle Komponente 
aufgerufen hat (Schritt 94) . Dies betrifft die Abschnitte 
22, 24 und 26 sowie den Lokaldatenbereich 32. Der Abschnitt 
des Arbeitsspeicherbereichs 16, der dem Zugrif f sdatenbereich 

0 30 der aufrufenden Komponente entspricht, wird dagegen nicht 
wiederhergestellt, so dafi eine Riickgabe von Werten im Zu- 
grif f sdatenbereich 30 von der aktuellen Komponente zur auf- 
rufenden Komponente moglich ist* 

5 Nach dem Wiederherstellen der aufrufenden Komponente ist die 
gegenwartige Instanz des in Fig. 4a bis Fig. 4c gezeigten 
Verfahrens beendet - Die Programmausf uhrung wird in der fru- 
heren Instanz an der Stelle fortgesetzt, an der der ur- 
sprungliche Komponentenauf ruf ausgelost wurde (Schritt 76) . 

0 

Durch die hier geschilderten Verfahren ist eine Funktionali- 
tatserweiterung von Komponenten auf relativ einfache Weise 
moglich. Beispielsweise sei eine Grundkomponente gegeben, 
die ein Preisf indungsverf ahren realisiert, das auf einem vom 

5 Benutzer (uber ein Eingabefeld) einzugebenden Einzelpreis 
basiert. Mittels einer geeigneten Erweiterungskomponente 
kann diese Grundkomponente urn ein anwendungsbezogenes Preis- 
f indungsverf ahren fur den Einzelpreis erweitert werden. Die 
Auf ruf information fur die Erweiterungskomponente wird dazu 

0 in einen Andockpunkt geschrieben, der dem Eingabefeld fur 
den Einzelpreis zugeordnet ist. Der von der Erweiterungs- 
komponente ermittelte Einzelpreis wird durch das Datenent- 
sorgungsverf ahren in die Grundkomponente eingeschrieben . 
Weitere Datenwerte, die die Erweiterungskomponente zur 

5 Preisfindung benotigt, werden durch das Datenbesorgungs- 
verf ahren aus anderen Komponenten abgerufen. Es ist nicht 
erf orderlich, dali bei der Programmierung der Grundkomponente 
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oder der anderen Komponenten die Moglichkeit einer solchen 
Funktionalitatserweiterung beriicksichtigt wurde. 

Die Programmierung von grolieren Sof twaresystemen lciflt sich 
auf unterschiedliche Weise vereinf achen. Zum Beispiel ist es 
moglich, sogenannte "Adapterkomponenten" zu definieren. Eine 
Adapterkomponente ist eine Erweiterungskomponente, die 
unmittelbar eine andere Komponente ref erenziert . Dadurch 
kann die andere Komponente mehrfach unter verschiedenen 
Namen verwendet werden. 
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Anspriiche 

1. Programmablaufverf ahren bei einem Programmkomponenten- 
5 system, das ein Lauf zeitsystem (14) und mehrere Komponenten 

(20, 20 *, ...) mit je einem Programmabschnitt (22) aufweist, 
mit den folgenden Schritten beim Ausfuhren des Programmab- 
schnitts (22) einer ersten Komponente (20) : 

a) durch das Lauf zeitsystem (14) vermittelte Datenbesor- 
0 gung von Daten einer zweiten Komponente (20') in die erste 

Komponente (20) unabhangig von programmiererdef inierten 
Schhittstellen in der zweiten Komponente (20'), und 

b) durch das Lauf zeitsystem (14) vermittelte Datenentsor- 
gung von Daten der ersten Komponente (20) in die zweite 

5 Komponente (20 1 ) unabhangig von programmiererdef inierten 
Schnittstellen in der zweiten Komponente (20')- 

2. Verf ahren nach Anspruch 1, 

dadurch gekennzeichnet , dafi die bei der Datenbesorgung uber- 
0 mittelten Daten von einem Speicherbildabschnitt (28) der 

zweiten Komponente (20 1 ) in einen Transf erdatenbereich (34) 
der ersten Komponente (20) ubertragen werden, und/oder dafi 
die bei der Datenentsorgung ubermittelten Daten von einem 
Transf erdatenbereich (34) der ersten Komponente (20) in 
5 einen Speicherbildabschnitt (28) der zweiten Komponente 
(20 1 ) ubertragen werden. 

3. Verf ahren nach Anspruch 1 oder Anspruch 2, 

dadurch gekennzeichnet, dafi die Datenbe- und/oder -entsor- 
0 gung ohne Mitwirkung der zweiten Komponente (20') erfolgt. 

4. Verf ahren nach einem der Anspriiche 1 bis 3, 

dadurch gekennzeichnet, daii die zweite Komponente (20* ) bei 
der Datenbe- und/oder -entsorgung inaktiv ist. 

5 

5. Verf ahren nach einem der Anspriiche 1 bis 4, 
dadurch gekennzeichnet, dali sich der Transf erdatenbereich 
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(34) der zweiten Komponente (20') bei der Datenbe- und/oder 
-entsorgung in einem Sicherungsbereich befindet. 

6. Verfahren nach einem der Anspriiche 1 bis 5, 
5 dadurch gekennzeichnet , dafi bei der Datenbe- und/pder 
-entsorgung lokale und/oder nicht-persistente Daten der 
zweiten Komponente (20') iibermittelt werden. 

7 . Verfahren nach einem der Anspriiche 1 bis 6; 
0 dadurch gekennzeichnet , dafi beim Ausfiihren des Programmab- 
schnitts (22) der ersten Komponente (20) vorgemerkt wird, 
fur welche Daten der ersten Komponente (20) eine Daten- 
entsorgung erforderlich ist. 

5 8. Verfahren nach einem der Anspriiche 1 bis 7, 

dadurch gekennzeichnet , dafi eine aufgerufene Komponente (20, 
20* , ...) unmittelbar auf einen Zugrif f sdatenbereich (30) 
zuzugreifen vermag, der die in der aufrufenden Komponente 
(20, 20' , .-..) definierten und/oder verfiigbaren Datenf elder 

0 enthalt. 

9. Verfahren nach einem der Anspriiche 1 bis 8, 

dadurch. gekennzeichnet, dafl der Aufruf einer Komponente (20, 
20 f , ...) durch eine Auf ruf information ausgelost wird, die 
5 in einem Andockpunkt der aufrufenden Komponente enthalten 
ist . 

10. Verfahren zur Erweiterung eines mehrere Komponenten 
(20, 20' , . . . ) aufweisenden Programmkomponentensystems um 

0 eine weitere Komponente, mit den Schritten: 

a) Suchen von Andockpunkten fur die weitere Komponente, 
die einem durch eine Definition der weiteren Komponente be- 
stimmten Vererbungsparameter entsprechen, in dem Programm- 
komponentensystem, und 

5 b) Andern derjenigen Komponenten (20, 20', .,.) des Pro- 
grammkomponentensystems, in denen mindestens ein Andockpunkt 
gefunden wurde, indem an jedem gefundenen Andockpunkt eine 
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Auf ruf information auf die weitere Komponente eingetragen 
wird. 



11. Verfahren nach Anspruch 10, ■ " 

5^ dadurch gekennzeichnet , daft alle Interaktionsschnittstellen 
der bisherigen Komponenten (20, 20 V, ...) als potentielle 
Andockpunkte vordefiniert sind. 

12. Verfahren nach Anspruch 10, 

0 dadurch gekennzeichnet, dafi alle von den bisherigen Kompo- 
nenten (20, 20', . ..) ref erenzierten Interaktions-Bild- 
schirmfelder und/oder alle Druckmasken-Ausgabef elder und/ 
oder alle Zugrif f soperationen auf persistente Daten als 
potentielle Andockpunkte vordefiniert sind. 

5 

13. Verfahren nach einem der Anspruche 10 bis 12, 
dadurch gekennzeichnet, dafi durch das Eintragen der Aufruf- 
information in einen Andockpunkt ein Aufruf der weiteren 
Komponente aus der Komponente, in die die Auf ruf information 

0 eingetragen wurde, vorbereitet wird. 

14. Verfahren nach einem der Anspruche 10 bis 13, 
gekennzeichnet durch den weiteren Schritt: 

c) Erzeugen mindestens eines Binarobjekts aus der Defini- 
5 tion der weiteren Komponente. 

15. Verfahren nach Anspruch 14, 

dadurch gekennzeichnet, dafi fur jeden gefundenen Andockpunkt 
hochstens ein Binarobjekt erzeugt wird. 

0 

16. Verfahren nach Anspruch 15, 

dadurch gekennzeichnet, daft bei der Erzeugung jedes Binar- 
objekts die Speicherzuteilung in derjenigen Komponente (20, 
20 1 , . . . ) des Programmkomponentensystems beriicksichtigt 
5 wird, die den zugrundeliegenden Andockpunkt enthalt. 
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Zusammenf assung 

Programmablaufverf ahren unci Verfahren zur Erweiterung eines 
5 Programmkomponentensystems 

Ein Programmablaufverf ahren bei einem Programmkomponenten- 
system, das ein Lauf zeitsystem (14) und mehrere Komponfenten 
(20, 20', ...) aufweist, enthalt eine durch das Laufzeit- 

0 system (14) vermittelte Datenbesorgung von Daten einer zwei- 
ten Komponente (20 1 ) in die erste Komponente (20) unabhangig 
von programmiererdef inierten Schnittstellen in der zweiten 
Komponente (20* ) und eine durch das Lauf zeitsystem (14) ver- 
mittelte Datenentsorgung von Daten der ersten Komponente 

5 (20) in die zweite Komponente (20 1 ) unabhangig von program- 
miererdef inierten Schnittstellen in der zweiten Komponente 
(20 1 ). Bei einem Verfahren zur Erweiterung eines Programm- 
komponentensystems urn eine weitere Komponente ist vorgese- 
hen f Andockpunkte fur die weitere Komponente zu suchen und 

0 diejenigen Komponenten (20, 20', ...) des Programmkomponen- 
tensystems, in denen mindestens ein Andockpunkt gefunden 
wurde, zu andern, indem an jedem gefundenen Andockpunkt eine 
Aufruf information eingetragen wird. Die Erfindung ermoglicht 
es, ein Programmkomponentensystem besonders flexibel und 

5 weitgehend zu erweitern. 



(Fig. 1) 
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